📋 Fiche d'Aide à la Décision

Version Client - Validation et Signature

En attente de validation 📅 24/11/2025

FAD

A person and person looking at a computer screen

AI-generated content may be incorrect. -

DOCUMENT D’ANALYSE FONCTIONNEL

-

FUNCTIONAL ANALYSIS DOCUMENT

Processus Achat

Microsoft Business Central

    1. ANAL

Almatech

Sommaire

1. Introduction 3

2. Vue d‘ensemble 4

3. Planification 5

4. Traitement d‘une livraison directe 6

5. Saisie d’une demande de prix 7

6. Saisie d’une commande cadre 8

7. Saisie d’une commande d‘achat 10

8. Saisie d’un retour d’une commande achat 12

9. Rapports achat 13

10. Historique achat 14

11. Annexe 1 : Liste d‘écarts 16

  1. Introduction

Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :

  • Visiter les sites clients comme les usines, entrepôts et/ou bureaux
  • Conduire des ateliers orientés processus.
  • Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
  • Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
  • Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
  • Identifier les volumes des référentiels et données transactionnelles
  • Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
  • Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.

Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :

Atelier

Date

Lieu

Almakom

Client

1er atelier

Nom et Prénom

Nom et Prénom

2ème atelier

Nom et Prénom

Nom et Prénom

Versions du document

Version

Date

Description

Ecrit par

Approuvé par

Draft

JJ/MM/AAAA

Draft

Nom et Prénom

Nom et prénom

JJ/MM/AAAA

Liste de diffusion

Membre de l‘équipe

Fonction

Email

Nom et Prénom

Nom et Prénom

  1. Vue d‘ensemble
    1. Schéma d’ensemble des processus achat

Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :

3 Planification

3.1. Contexte et Hypothèses

**3.1. Contexte et Hypothèses**

Le processus d'achat au sein d'Almatech est complexe et implique plusieurs types d'achats, notamment des offres, des projets et des achats génériques. Les achats sont mutualisés multi-projet, ce qui signifie que les besoins des différents projets sont gérés de manière centralisée.

Il existe deux options pour gérer les achats : l'option "industrielle" qui nécessite un stock minimum et une proposition de commande, ou l'option "spécifique" qui permet d'anticiper ou de constater les besoins de chaque projet. L'option "spécifique optimisée" combine ces deux approches en concevant des pièces standard et en complétant le stock avec des achats nécessaires.

La réception des pièces est un processus à revoir, notamment en ce qui concerne la difficulté de savoir où se trouve le colis. Le processus de "incoming" implique un contrôle et une réception de la livraison, avec photos du colis non ouvert et ouvert, ainsi que la possibilité de créer un document de qualité.

Les petits achats sont soumis à une chaîne d'approbation qui dépend du seuil fixé par la personne qui passe la commande ou du risque sur la commande. Les critères d'approbation incluent l'achat dans le budget ou non.

Le système de gestion des achats actuel est incomplet et nécessite des fonctionnalités telles que le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système, et l'intégration des coûts de transport liés à la commande.

La réception des pièces est actuellement mal gérée, avec pas de visibilité sur le statut de livraison et pas d'inspection systématique à la réception. Le processus d'incoming implique un contrôle qualité léger ou approfondi, suivi d'un échange avec le fournisseur en cas de non-conformité.

Les stocks sont gérés dans plusieurs lieux, notamment l'EPFL et Payerne, et le référentiel fournisseur nécessite un suivi des lead times fournisseurs et la prise en compte des différents plannings.

Enfin, les devis et commandes nécessitent un numéro de projet obligatoire, ainsi que la gestion des Incoterms et la partie shipping à détailler ultérieurement.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

3.2. Schéma des processus ERP : Planification 1.0

3.3. Principales règles de gestion

Dans le processus de planification, le client met en place des règles de gestion métier pour gérer les achats de manière efficace.

La première règle consiste à effectuer un contrôle et une réception de la livraison, même si le paiement est effectué en avance. Le client utilise la fonctionnalité de gestion des certificats par la Qualité Contrôle pour gérer les informations liées à la livraison, y compris les livraisons partielles.

Le client peut créer un document de contrôle qualité qui résume les choses à contrôler, demande des photos et le numéro de lot ou série (si paramétré en tant que suivi par lot). La qualité doit valider le processus en validant le document de contrôle qualité.

Le Chef de Projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi. Lorsqu'un Incoterm est renseigné, la ville doit être précisée.

La création d'un document de contrôle qualité est une étape clé dans le processus. Lorsque le responsable qualité valide le document, la réception est validée. Le client a également la possibilité de réceptionner sans contrôle qualité immédiat, puis de réaliser le contrôle plus tard au niveau des séries/lots.

Dans Microsoft Dynamics 365 Business Central, ces règles de gestion métier peuvent être pris en charge ou automatisées à l'aide de la fonctionnalité de workflow validation. Le client peut paramétrer les règles de validation pour s'assurer que les contrôles qualité sont effectués correctement et que les réceptions sont validées en temps opportun.

3.4. Documents et statistiques

Planification des documents et statistiques

La planification des documents et statistiques est cruciale pour l'optimisation des processus de gestion de l'entreprise. Pour ce faire, il est essentiel de disposer d'un système de gestion des documents efficace.

Création de documents de contrôle qualité

L'atelier crée un document de contrôle qualité pour chaque série, lot et commande. Ce document est créé en fonction du type de document d'inspection :

- 1 document par série
- 1 document par lot
- 1 document par commande (s'il n'y a pas de série ou lot)

Ce document est essentiel pour garantir la traçabilité et la qualité des produits.

Gestion des documents d'entrée en stock

Actuellement, il n'y a pas de document d'entrée en stock. Cependant, il est prévu de créer un document par n° de série (et éventuellement plusieurs séries) et plusieurs documents.

Gestion des documents dans SharePoint

Il est prévu de gérer les documents dans SharePoint. Cela permettra de stocker et de partager les documents de manière sécurisée et efficace.

Workflow de validation

Il est nécessaire de mettre en place un workflow de validation pour garantir que les documents sont correctement créés et vérifiés avant d'être utilisés.

Journal des achats

Le journal des achats est un outil essentiel pour suivre les achats et les commandes. Il est nécessaire de configurer ce journal pour suivre les documents de contrôle qualité et les documents d'entrée en stock.

Fiche article

La fiche article est un outil essentiel pour gérer les informations relatives aux articles. Il est nécessaire de configurer cette fiche pour suivre les documents de contrôle qualité et les documents d'entrée en stock.

En résumé, la planification des documents et statistiques est cruciale pour l'optimisation des processus de gestion de l'entreprise. Il est nécessaire de mettre en place un système de gestion des documents efficace, de configurer le journal des achats et la fiche article, et de mettre en place un workflow de validation pour garantir la qualité et la traçabilité des documents.

3.5. Volume des données

Dans le processus de planification, les données sont essentielles pour prendre des décisions éclairées. Le volume des données est un aspect clé à considérer pour garantir que les informations sont fiables et cohérentes.

Pour déterminer le volume des données, il est important de prendre en compte les lignes budget qui remontent le coût budgété ou le montant réel dans la commande. Les champs "coût budgété" et "montant réel" sur les lignes budget sont utilisés pour suivre les dépenses et les coûts associés aux projets.

Les dates de planification dans les lignes projet sont également importantes pour comprendre les délais et les échéances des projets. Cependant, il n'est pas explicitement mentionné comment ces dates sont utilisées pour calculer le volume des données.

Il est possible de configurer des workflow de validation pour s'assurer que les données entrées sont correctes et cohérentes. Cependant, l'existence de tels workflow n'est pas mentionnée dans les notes sources.

Il est également important de prendre en compte le journal des achats pour suivre les commandes et les livraisons associées aux projets. Cependant, il n'est pas explicitement mentionné comment les données du journal des achats sont utilisées pour calculer le volume des données.

En résumé, pour déterminer le volume des données, il est important de prendre en compte les lignes budget, les dates de planification et le journal des achats. Cependant, certaines informations sont manquantes et doivent être complétées pour obtenir une vision complète du processus de planification.

3.6. Écarts critiques et interfaces

Identifier les écarts critiques entre le processus actuel de planification et les bonnes pratiques ou les exigences cibles du projet.

Le processus actuel de planification n'est pas explicitement décrit dans les notes sources. Cependant, on sait que la qualité est importante pour bloquer les livraisons et que les informations de lot sont prises en compte.

Les bonnes pratiques pour la planification incluent la gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée. Cela nécessite la mise en place d'un workflow validation pour garantir que la qualité est vérifiée avant la livraison.

Les interfaces nécessaires entre le système cible et les autres applications, services ou départements impactés incluent :

- Le journal des achats pour suivre les commandes et les livraisons.
- La fiche article pour gérer les informations de produit.
- La comptabilité pour gérer les factures et les paiements.

Il est important de noter que la gestion des écarts critiques nécessite une analyse approfondie des processus actuels et des exigences cibles du projet. Cela nécessite également la mise en place d'un plan de travail pour clôturer les écarts d'ici la fin de la phase d'Analyse.

Enfin, il est essentiel de définir les seuils pour déclencher les écarts critiques, qui dépendent de la personne qui passe la commande ou du risque sur la qualité. Cela nécessite une collaboration étroite avec les différentes parties prenantes pour garantir que les écarts critiques sont bien identifiés et résolus.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

4 Traitement d‘une livraison directe

4.1. Contexte et Hypothèses

**4.1. Contexte et Hypothèses**

Le processus de traitement d'une livraison directe à Almatech est complexe et nécessite une gestion minutieuse des différents étapes, des fournisseurs et des projets. Le contexte actuel est marqué par des difficultés de visibilité sur le statut de livraison, des inspections systématiques à la réception inexistantes et des problèmes de traçabilité des pièces.

Les points critiques de ce processus sont :

* La réception des colis sans visibilité sur le statut de livraison
* L'absence d'inspection systématique à la réception
* La difficulté de traçabilité des pièces
* La nécessité de gérer les certificats pour les pièces VOL
* La gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée

Les attentes client sont :

* Une visibilité claire sur le statut de livraison
* Une inspection systématique à la réception
* Une traçabilité des pièces
* Une gestion efficace des certificats pour les pièces VOL
* Une gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée

Les hypothèses qui peuvent avoir un impact sur le projet sont :

* La mise en place d'un flux d'approbation formalisé pour les commandes
* La gestion des coûts de transport liés à la commande
* La discussion avec la comptabilité concernant la gestion des frais de transport
* La définition du processus détaillé d'inspection et des types de documents d'inspection

Il est important de noter que certaines informations sont manquantes, telles que la description du processus de réception actuel et les critères d'approbation pour les commandes.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0

4.3. Principales règles de gestion

Création d'un document de contrôle qualité : lorsqu'un responsable qualité valide, la réception est validée.

Le client exige un contrôle qualité avant de valider la réception de la livraison. Le processus de contrôle qualité est initié par le Chef de Projet (CP) qui décide du niveau de contrôle qualité requis, léger ou approfondi.

Lorsqu'un Incoterm est renseigné, la ville doit être précisée. Le responsable qualité crée un document de contrôle qualité qui résume les éléments à contrôler, demande des photos et des informations sur le numéro de lot ou série si paramétré.

Le document de contrôle qualité peut être créé avant ou après la réception de la livraison. Si la réception est effectuée sans contrôle qualité immédiat, le contrôle peut être réalisé plus tard au niveau des séries/lots.

L'ERP Microsoft Dynamics 365 Business Central peut gérer ce processus en créant un document de contrôle qualité qui est lié à la fiche article et au journal des achats. Lorsque le responsable qualité valide le document, la réception est automatiquement validée.

Un workflow validation peut être mis en place pour garantir que le processus de contrôle qualité est respecté et que la réception est validée uniquement lorsque le document de contrôle qualité est approuvé.

En résumé, le processus de contrôle qualité est essentiel pour valider la réception de la livraison et Microsoft Dynamics 365 Business Central peut aider à gérer ce processus de manière efficace.

4.4. Documents et statistiques

Traitement d'une livraison directe : Documents et statistiques

Lors du traitement d'une livraison directe, les documents suivants doivent être imprimés :

- Un document de contrôle qualité pour chaque série, lot ou commande, selon les types de documents d'inspection spécifiés.
- Un document par n° de série, avec la possibilité d'avoir plusieurs séries pour un même document.

Les états et statistiques métiers attendus incluent :

- Le tableau de bord adapté au profil de l'utilisateur, qui doit afficher les informations pertinentes pour ce processus.
- Les documents de type spécification, qui devraient être gérés dans SharePoint.

Il est important de noter que, actuellement, il n'y a pas de document d'entrée en stock, ce qui constitue une difficulté pour le chef de projet.

En ce qui concerne les statistiques, il est possible de suivre les informations suivantes :

- Le nombre de séries, lots ou commandes traitées.
- Le nombre de documents de contrôle qualité générés.
- Le nombre de documents par n° de série.

Ces informations peuvent être utilisées pour suivre l'avancement du processus et identifier les zones d'amélioration.

4.5. Volume des données

Traitement d'une livraison directe :

- Pour traiter une livraison directe dans Microsoft Dynamics 365 Business Central, il faut créer une commande de vente en utilisant la fonctionnalité "Commande de vente" (Sales Order).
- La commande de vente est ensuite traitée par le workflow de validation (Workflow Validation) pour vérifier les informations de livraison.
- Une fois validée, la commande de vente est convertie en une livraison directe (Direct Shipment) qui est enregistrée dans le journal des livraisons (Shipment Journal).
- La livraison directe est ensuite traitée pour la facturation et l'enregistrement des coûts.

Volume des données :

- Le volume des données référentielles pour le traitement d'une livraison directe est relativement faible.
- La création d'une commande de vente nécessite environ 5-10 lignes pour les articles (fiches article) concernés.
- Le journal des livraisons (Shipment Journal) enregistre les informations de livraison directe pour chaque commande de vente traitée.
- Le nombre de documents par période est généralement faible, environ 1-5 documents par jour pour les commandes de vente et les livraisons directes.
- Les lignes budget (Budget Lines) sont utilisées pour remonter le coût budgété ou le montant réel dans la commande, mais ce n'est pas une information pertinente pour le traitement d'une livraison directe.
- Les dates de planification dans les lignes projet (Project Lines) ne sont pas directement liées au traitement d'une livraison directe.
- Le numéro de projet et les tâches projet à renseigner sur les lignes pour permettre la consommation sur le projet ne sont pas pertinents pour le traitement d'une livraison directe.

4.6. Écarts critiques et interfaces

Initialisation des écarts critiques et interfaces

Lors du traitement d'une livraison directe dans Microsoft Dynamics 365 Business Central, il est essentiel d'identifier les écarts critiques et les interfaces qui pourraient affecter la qualité et la conformité de la livraison.

Écarts critiques :
- Les écarts critiques peuvent être identifiés en fonction du seuil défini par la personne qui passe la commande ou du risque associé à la livraison. Ce seuil peut être défini en fonction du document de qualité et peut même permettre de bloquer les livraisons si les écarts sont trop importants.
- La gestion des statuts dans Business Central permet de bloquer la facture en comptabilité si la qualité n'est pas validée.

Interfaces :
- Les informations de lot sont essentielles pour identifier les écarts critiques et les interfaces. Cependant, [INFORMATION MANQUANTE] sur la manière dont ces informations sont utilisées pour initialiser les écarts et les interfaces dans la liste des écarts délivrée.

Initialisation des écarts et interfaces :
- Les écarts critiques et les interfaces identifiés doivent être initialisés dans la liste des écarts délivrée.
- La liste des écarts délivrée doit être finie à la fin de la phase d'Analyse.

Il est important de noter que [INFORMATION MANQUANTE] sur la procédure exacte pour initialiser les écarts et les interfaces dans Business Central. Cependant, il est recommandé de consulter le document de qualité et de suivre les instructions pour garantir la qualité et la conformité de la livraison.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

  1. Saisie d’une demande de prix

5.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

    1. Schéma des processus ERP : Demande de prix 3.0

5.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

5.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

5.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

5.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

6 Saisie d’une commande cadre

6.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0

6.3. Schéma des processus ERP : Saisie d’une commande d’achat

6.4. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

6.5. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

6.6. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

6.7. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

7 Saisie d’une commande d‘achat

7.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

7.2 Schéma des processus ERP : Saisie d’une commande d’achat

7.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

7.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

7.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

7.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

8 Saisie d’un retour d’une commande achat

8.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0

Une image contenant texte, capture d’écran, diagramme, Police

Le contenu généré par l’IA peut être incorrect.

8.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

8.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

8.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

8.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

9 Rapports achat

9.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

9.2 Schéma des processus ERP : Rapport achat 8.0

9.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

9.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

9.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

9.6. Ecarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

10 Historique achat

10.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

10.2 Schéma des processus ERP : Historique achat 9.0

10.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

10.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

10.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

10.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

11 Annexe 1 : Liste d‘écarts

11.1. Liste d’écarts

La liste d’écart doit être initialisée et finalisée à la fin de la phase d’analyse.

Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).

Vos Remarques

Validation et Signature

Approuver

Je valide ce document

Approuver sous réserve

Valide avec des réserves

Refuser

Je ne valide pas ce document